System and method for identifying problems via a monitoring application that repetitively records multiple separate consecutive files listing launched or installed applications

ABSTRACT

A system and method for discovering fault conditions such as conflicts between applications and an operating system, driver, hardware, or a combination thereof, installed in mobile computing devices uses a mobile device running a diagnostic application. A list of applications that were launched or installed during a time period prior to an operational disruption is retrieved. A data table of combinations of incompatible programs and drivers is used to analyze the list of the applications that were launched or installed to create a list of potential fault-causing interactions due to software incompatibilities of software installed in the mobile computing device. A knowledge database is updated with data identifying at least one of the potential fault-causing interactions. Further disclosed is a computer program that identifies hardware-created or software-created problems and operational disruptions in mobile computing devices by collecting data on incompatibilities in particular mobile computing devices on the internet.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority to United States ProvisionalPatent Application Ser. No. 61/575,140 entitled “Enhanced System AndMethod For Identifying Software-Created Problems And OperationalDisruptions In Mobile Computing Devices With Cellular Connections (SmartPhones),” filed on Aug. 16, 2011, the disclosure of which is herebyincorporated herein in its entirety by reference.

BACKGROUND

Often, transferring data in phones can be very cumbersome. Inparticular, modern phones may hold multiple gigabytes of data comprisingpictures and other graphical representations, address records, emails,etc. Data traffic resulting from transfer of such data from one phone toanother, or to a backup storage medium, creates a data bottleneck fordata transfer stations such as wireless service providers and otherstores that offer such data transfer services.

FIG. 1 shows two typical telephone/PDA device data transfer stations. InFIG. 1A, transfer station 100 has a phone data transfer machine (PDTM)110, typically a PC with USB and Bluetooth connectivity running phonedata transfer applications such as PC Suite, PC Tools and otherphonebook transfer applications, which typically may connect to twohandsets: originating handset 101 and a receiving handset 102. Saidconnections are typically made via USB cables 103 or custom cables 104.Each phone has its own operating system with software 101 a and 102 a,respectively, and data sets 101 b 1-n and 102 b 1-n, respectively. Thisdata may contain a variety of information, including, but not limitedto, address book data, phone numbers, email addresses, pictures, videoclips, and other types of data that may be used by cell phones and theirapplications. In some cases even the applications installed on the phoneand/or the application data may be transferable. Typically, machine 110would have its own operating system 110 a, which has multiple programs110 b. Often, machine 110 with operating system 110 a and programs 110 bis actually a custom, dedicated PC, and as such it has to containdrivers or DLLs 110 c for all the phones to which it may be connected.As a result of having a large library of DLLs (or drivers, usedinterchangeably here) almost any data transfers between two differentphones can work. The machine can, by using the DLLs, communicate anddownload the data objects (each item typically comes down as one or moredata objects from the phone), which are then stored in machine 110temporarily and eventually sent on to the other phone, as its dataobjects, using the matching DLL. Each of these devices has a CPU andmemory, both volatile and nonvolatile, and thus each forms a small,distinct computing device.

FIG. 1 b shows another type of known data transfer station 120. Copymachine 121 has only one connector. It is first plugged into theoriginating machine 101, using connection 105, via which connection thedata is transferred into machine 121. Then the receiving device 102 isconnected by a cable connection 106 (dotted) in a second step, and thatconnection is used to transfer the data from machine 121 to phone 102.Again, these devices have operating systems, programs, and DLLs, asdescribed above in the discussion of FIG. 1A.

A large cost is inflicted on cellular network operators by the userpractice of returning devices for repair or exchange that are notactually defective. There are several reasons for this problem: someoperating intermittencies may not be caught during in store testing of adefective device, or the problem may be caused by peripheral devicesthat are not returned with the supposedly faulty phone. A large portionof the problem may be attributed to user configuration errors, networkconfiguration errors, or user software add-ons that are installable inthe phone but may not be completely compatible with the particular phoneset up and its particular network. Only a small fraction of returns aredue to actual failure of the hardware. However, efficient and expedientrepair of handsets is very important, because the cost of each handsetrepair affects the final profitability of an operator. One of the mostimportant aspects of handset repair is efficiently achieving a specificlevel of program and data sets in a repaired handset.

In some cases, more thorough diagnostics of devices with problems areneeded than the diagnostics that are available currently. Thesediagnostics should not merely rely on internal functional diagnostics,but they should also include hardware configuration diagnostics, programconfiguration diagnostics, and network configuration diagnostics; andthey should also look for other factors, including but not limited toprogram compatibility issues.

Often, the exchange of data objects between different phones is desiredor required. Some phones do not support such a feature; other phoneshave a very limited ability in this regard. For example, such phones mayallow exchange of an object such as a business card, but do not supportexchange of photos, videos or other larger graphic images.

In some cases wired telephone connections may be difficult or impossibledue to defective connectors, unavailable infrastructure, etc.

Some telephone devices are notoriously difficult to access with anin-store diagnostic device, be it wirelessly or via wired connection. Inthe context of universal serial bus (USB) devices, the manufacturers aresupposed to use vendor ID (VID) and product ID (PID) numbers todistinctly identify every product.

These VID/PID numbers are often also used in other connectivity schemes,including but not limited to Bluetooth (BT), local area network (LAN)and over the Internet. These access problems occur due to variouslegitimate or not-so-legitimate reasons, and more frequently, devicemanufacturers either re-use the same VID/PID numbers for differentdevices to save money on registration fees, or in other cases, afly-by-night garage-style manufacturer clandestinely produces a seriesof few hundred or a few thousand devices and then closes up shop. Thisis often because such phones infringe copyrights or other intellectualproperty, pretending to be brand-name manufacturers' phones, but usingdifferent components, such as chips. Despite these problems, it issometimes desirable for an operator, such as, for example, anindependent store operator, to provide service nevertheless, doing so tomaintain good customer relations, rather than to rebuff or annoy acustomer.

In many cases, it is desirable to back up the data on a mobilecommunication device with a back-up device that does not require aconnection to a standard computer, such as, for example, the exemplarycomputer of FIG. 7. For example, when a person with a mobilecommunication device is traveling away from the office, sometimes it isnecessary or desirable to travel without a computing device such as alaptop computer; however, a person may still need to back up the data inhis or her mobile communication device.

SUMMARY

In an embodiment, a computer-implemented system and method fordiscovering fault conditions due to software incompatibilities ofsoftware installed in mobile computing devices having a cellularconnection is disclosed. The system and method use a mobile devicerunning a diagnostic application. A list of applications that werelaunched or installed during a time period prior to an operationaldisruption is retrieved. A data table of combinations of incompatibleprograms and drivers is used to analyze the list of the applicationsthat were launched or installed to create a list of potentialfault-causing interactions due to incompatibilities of software and/orhardware installed in the mobile computing device. A knowledge databaseis updated with data identifying at least one of the potentialfault-causing interactions. In an embodiment, a computer programimplements a method for identifying software-created problems andoperational disruptions in mobile computing devices with cellularconnections. The program includes code for causing a computer to connectto the internet and collect data on incompatibilities in particularmobile computing devices on the internet by scanning websites. Theprogram includes code for using the collected incompatibility data tocreate a list of harmful combinations of model IDs, OS versions, orother device characteristics that in conjunction with one or moreprograms negatively impact the user experience.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B show an exemplary conventional telephone/PDA device datatransfer station;

FIG. 2 an example of a typical telephone/personal data assistant (“PDA”)device data transfer station which can be utilized with the system andmethod according to the disclosed subject matter;

FIG. 3 shows an exemplary process for data transfer;

FIG. 4 shows an overview of an exemplary transfer station;

FIG. 5 shows a simplified overview of an exemplary testing system;

FIG. 6 shows an exemplary process for implementation of system testsoftware;

FIG. 7 shows an exemplary overview of a computer system as may be usedin any of the various locations throughout disclosed system.

FIG. 8 shows a more detailed overview of an exemplary system similar totypical telephone/PDA device data transfer stations;

FIG. 9 shows an exemplary process for implementation of enhanced systemtest software;

FIG. 10 shows a simplified overview of two phones that are communicatingwith each other, according to one embodiment of the disclosed system;

FIG. 11 shows an exemplary process of the interaction between the twophones according to one embodiment of the disclosed system;

FIG. 12 shows a block diagram illustrating a transfer station;

FIG. 13 shows an exemplary process for discovering the actual identityof a telephone device;

FIG. 14 shows an overview of an exemplary table;

FIG. 15 illustrates a system and method for exchanging drivers;

FIG. 16 shows an overview of an exemplary device according to one aspectof the system and method disclosed herein;

FIG. 17 shows an overview of device architecture;

FIG. 18 shows a detailed overview of an exemplary system for updatingsoftware in a device;

FIG. 19 shows a detailed overview of an exemplary system for updatingsoftware in a device;

FIG. 20 shows an exemplary process for backing up data from a mobilecommunication device;

FIG. 21 shows an enhanced system according to one aspect of the systemand method described herein;

FIG. 22 shows a bus and interface system;

FIG. 23 shows an enhanced USB PCI card;

FIG. 24 shows an overview of an exemplary system for enhanceddiagnostics;

FIG. 25 shows an exemplary process for implementation of the systemaccording to one aspect of the system and method disclosed herein;

FIG. 26 shows an overview of the data flow as it is analyzed;

FIG. 27 shows an overview of an exemplary screenshot according to oneaspect of the system and method disclosed herein;

FIG. 28 shows an overview of an exemplary screenshot according to oneaspect of the system and method disclosed herein;

FIG. 29 shows an overview of an exemplary screenshot according to oneaspect of the system and method disclosed herein;

FIG. 30 shows an overview of an exemplary screenshot according to oneaspect of the system and method disclosed herein;

FIG. 31 shows an overview of an exemplary screenshot according to oneaspect of the system and method disclosed herein;

FIG. 32 shows an overview of a system for identifying software-createdproblems and operational disruptions in smart phone computing devicesand other mobile computing devices with cellular connections;

FIG. 33 shows an exemplary process for data retrieval and analysis bysystem software running on a computer or server.

DETAILED DESCRIPTION

What is needed is a system and method for tracking and detecting devicefailures, and by doing so analyzing the problems and detecting theincorrect return of hardware, thus reducing dramatically the overallcost of network operations.

Additionally needed is an enhanced system and method to collectinformation about faults and problems mostly created by misbehaving ormalicious applications. However, any problems between applications andoperating system, driver, hardware, other apps, or any combinationthereof due to software incompatibilities of hardware or of softwareinstalled in said mobile computing device can be observed and recorded.Also needed is an enhanced system and method that not only takes intoaccount statistical data collected from software recording, but furtheradds information gleaned from social networking sites, technical forumsites, etc., relevant to the specific models of mobile communicationdevices.

What is further needed is a system and method that allows data transferbetween phones without requiring PDTMs such as 110 or 121, thus allowingthe user to transfer data at his own pace and, if multiple transfersmust be done, they can be done concurrently, because limited resources,such as copy machine 110 or 121, are generally not required.

Further, it is desired, that such a system operates cross-platform. Forexample currently, a Palm device can beam to another Palm device and aNokia device can beam to another Nokia device, but currently a Palmdevice cannot beam to a Nokia device and vice versa, or to phonesmanufactured by any other manufacturer, by in large. Some exceptionsexist within limited groups of some devices by different manufacturersthat use same operating systems.

What is further needed is a system and method that, using a small,portable device such as a USB key, can create backups directly frommobile communication and personal computing devices.

What is additionally needed is a system and method for tracking anddetecting device failures, and by doing so analyzing the problems anddetecting the incorrect return of hardware, thus reducing dramaticallythe overall cost of network operations.

In most cases, manufacturers need to preload client software to at leastone if not both devices for a beaming operation to work. In anembodiment, the present invention does not require client software to bepre-installed. In this respect, the device containing the “old” data canbe communicated with as if a computer is communicating with the device.This functionality is generally is supported on the mobile phonedevices, even on older models, in their stock configuration withoutadditional special purpose applications being installed. In anembodiment, the “old” phone is interfaced with using stock interfacesalready on the phone, for example by an application installable on a PCthat allows the PC to read from devices through a USB cable withoutfirst having to pre-install a client. Further, the wireless technologyused by the device does not matter, as it can read can read from bothCDMA and GSM phones, like the PC based tool.

FIG. 2 shows an example of a system 200 according to one embodiment ofthis disclosure. In this example, the receiving phone 202 may beconnected, either by wired or wireless connection, to the originatingphone 101, as indicated by connection lines 201 a-n. This connectioncould be via Wi-Fi ad hoc connection, Bluetooth connection, wiredconnection, or in some embodiments an over-the-air network connection.In an embodiment, the originating phone 101 has, as before, an operatingsystem 101 a and a data set 101 b 1-n. The receiving phone 202 has thesame software; however, additionally, the operating system 202 acontains applications 212 a-n, at least one of which (referred to hereinas 212 x, not shown) is the copying software. This software may be, forexample, downloaded from a network provider and installed in the phoneor, in some embodiments, pre-installed in the phone by the manufacturer.More than one type of copying software may be required, depending on thevarious different phones involved in a transfer, but requiring only oneapplication for a given new phone. Copying software 212 x has access toa complete set of drivers and DLLs 213 a-n, which drivers and DLLs maybe required for various different phones. The complete library ofdrivers and DLLs may be pre-installed in the originating phone andupdated through the Internet. In some embodiments, these drivers andDLLs 213 a-n may not be downloaded until phones 202 and 101 are paired,so that only the driver(s) and DLL(s) for the specific paired devicesare downloaded. In other embodiments, some or all available drivers andDLLs may be downloaded, but some or all drivers and DLLs may be removedlater to free up memory in the receiving device 202. As previouslymentioned, devices such as phone 202, and optionally phone 101, aregenerally known as smart phone computing devices or other mobileInternet/computing devices, including, but not limited to, smart phones,tablets, etc. Typically these devices have a very powerful CPU, arelatively large amount of memory of different kinds (including but notlimited to RAM, flash, removable media, etc.), input devices, displaydevices, speaker, microphone, and other such components and a softwareoperating system 202 a, so that they are actually fully functional,hand-held computing platforms, with functionality limited only by theirsize and sometimes by restrictions of their operating system 202 a. Insome embodiments, the copy software and adapted or simulated DLLs may beadapted to run on the phone's operating system (“OS”), and in otherembodiments an additional OS that runs within a protected environment(similar to a virtual machine) but allows use of unmodified DLLs may beprovided.

FIG. 3 shows an exemplary process 300 for data transfer according to oneembodiment of the disclosed system. In step 301 the copy application isdownloaded into a receiving phone such as phone 202. In this example,the download is via network 303 from data repository 305 that resides inserver 304 and that contains copy applications for all supported phones.In step 302, DLLs are loaded into device 202, also from data repository305 in server 304. As mentioned previously, this step may occur onlyafter connection with an originating phone such as phone 101 isestablished. In step 306, the connection is established with originatingphone 101. As previously described, this connection may be made via anyof various types of connectivity means that are currently known in theart or that may in the future be developed and made publicly available.In all cases, the connection process would involve a confirmation orpass code, such as the process currently used for the connection ofBluetooth devices. In some cases, this connection would actually bebetween two Bluetooth devices, but in other cases a similar processcould be emulated via the phone number and passwords over the network orover a physical wire. In step 308 the system tests the originatingdevice 101 to determine its specific model. This testing typicallyrequires some user approval 307 or a user action on the originatingphone, either of which may also act as a privacy protection (sometimesit may be part of communication protocols, such as pairing of BlueToothdevices. etc.). Then typically the DLL 213 x for that specific model isloaded for use by the copying software 212 x. This DLL could be loadedfrom the library downloaded in step 302, or it could be requested fromthe data repository 305 via over-the-air network or other suitableconnections. In step 309, the system downloads data from device 101. Tothe internal intelligence (software and firmware) of device 101, thisprocess appears to occur just as if the device were connected to acomputer. In step 310 the system then converts or adapts the downloadeddata objects to the requirements of the receiving phone 202 by means ofanother DLL, which essentially mimics the process of the download tointernal database 202 b 1-n. In step 311 the data is then downloadedinto database 202 b 1-n. In step 312 the user is notified that the datadownload is complete, and in step 313 the process ends. Progress of thevarious procedures may be displayed to the user via progress bars on thedisplay device of the receiving phone, showing the progress as apercentage of the overall process or as a percentage of a typicalprocess. Such a progress display is commonly used and well known incomputing devices.

FIG. 4 shows an overview of an exemplary station 400 similar to typicaltelephone/PDA device data transfer stations as are currently in use. InFIG. 4, phone data transfer machine (PDTM) 410 is typically a PC orother suitable computing device with USB and Bluetooth connectivityrunning phone data transfer applications such as PC Suite, PC Tools andother phonebook transfer applications, which typically may connect oneor two handsets, such as the handset of a device under test (DUT) 401 asshown in FIG. 4. Said connections are typically made via USB cables 403or custom cables 404 (not shown). Each phone has its own operatingsystem with software 401 a and data sets 401 b 1-n. This data maycontain all kinds of information, including, but not limited to, addressbook data, phone numbers, email addresses, pictures, video clips, andother types of data that may be used by cell phones and theirapplications. In some cases even the applications or the applicationdata may be transferable. Typically machine 410 would have its ownoperating system 410 a, which has multiple programs 410 b, including atest application 410 b 1 (not shown separately). Often machine 410 withoperating system 410 a and programs 410 b is actually a custom,dedicated PC, and as such it has to contain drivers or DLLs 410 c forall the phones to which it may be connected. As a result of having alarge library of DLLs (or drivers, used interchangeably here) almost anydata transfers between two different phones can work. The machine can,by using the DLLs, communicate and download the data objects (each itemtypically comes down as one or more data objects from the phone), whichare then stored in machine 410 temporarily and eventually sent on to theother phone, as its data objects, using the matching DLL. It is clearthat each of these devices has a CPU and memory, both volatile andnonvolatile, and thus each forms a small, distinct computing device.

FIG. 5 shows a simplified overview of an exemplary testing system 500,using the same DUT 401, according to one aspect. Here, rather than beingconnected to a hardware testing device, a test application 410 b 1 (notshown separately) may, for example, be downloaded over the network 502from a server 504, or from its data repository 506. In some cases thePDTM 410 may tell the server 504 which device, identified by its ESN,IMEI, phone number, etc., should receive the application, as the networkoperator has the ability to send special system messages to remotelyinstall software on devices.

FIG. 6 shows an exemplary process 600 for implementation of the systemtest software. In step 601 the system downloads a monitoring applicationonto a target device. In step 602, the system obtains user permission torun the application. In addition to asking a simple Yes or No question,the system may require the user to enter a password, such an accountpassword or the user password for this device, to verify that this isnot an illegal attempt to install software on the device.

In step 603, the program starts to monitor user and device activities,including but not limited to such as cell changes, roaming tableupdates, installation and activation of software applications,installation and activation of plug-in software, phone calls, etc. Othermonitored data includes a preferred roaming list (PRL), batteryoperation, temperature control, logging of RF signal in and out duringvarious operations, etc. In some cases, it is also possible to obtain aprecrash memory dump, which may be stored in the local storage 401 c ofdevice 401. Local storage 401 c may be, for example, a segregatedsection of nonvolatile memory in the device, which would preferablysurvive a crash without losing data.

The monitoring application preferably repetitively writes a list ofapplications that were launched or installed to flash memory of thedevice in multiple consecutively written files. In an embodiment, themonitoring application repetitively writes the list of applications tothree consecutively written files in the flash memory in the followingmanner. A first file is opened, data is written to the file, and thefirst file is closed. A second file is then opened, data is written tothe file, and the file is closed. A third file is then opened, data iswritten to the file, and the file is closed. The process is thenrepeated, with the first file being opened, data written to it, thefirst file closed, and so on. If multiple files are used in this mannerin an ongoing monitoring process, then it is much more likely that atleast one of the files will be readable and not corrupted after an eventsuch as when the user pulls the battery, when the user performs a hardreset, or the when the device crashes. Furthermore, a snapshot of thestate of the device can be reconstructed from a combination of two ormore of the multiple files after such event even if one of the files iscorrupted by the event. In an embodiment, the monitoring application isconfigured to selectively upload the data files to a central datarepository only when a Wi-Fi connection is available to the device so asnot to incur data usage charges. This mode of operation is particularlyuseful where the user of the device does not have an unlimited dataplan, and pays per-megabyte or per-gigabyte charges for data usage.

Also, in step 604 the system monitors the remaining capacity of localstorage 401 c. When the storage 401 c reaches a preset threshold ofoccupied space (yes), it is considered full and the process moves tostep 605, where the system now sends data to data repository 506 onserver 504, from where it can be analyzed either automatically or ondemand when a customer comes to a store or repair depot to complainabout the phone. From step 605 or, if the local storage is not yet full(no), from step 604, the process moves to step 606. There, the systemanalyzes the data transmitted by the downloaded application and storedeither in local storage 401 c or data repository 506. If the system doesnot detect a fault, the process loops back to step 603, where the systemcontinues to monitor the device. If the system detects a fault or otherrelevant state or event (yes), the process moves to step 607, where thesystem sends a fault indication to data repository 506 of server 504.Server 504 may be running programs to respond to the fault indicationby, for example, sending an email to the user of device 401 explainingthe problem. A copy of this email may also be sent to the phone number'saccount log at the network operator's system, or, in other cases, onlyto the network operator's system. After the email is sent, the processloops back to step 603, where the system continues to monitor thedevice. By anonymizing certain data, abuses of the data may be reduced.Also, server 504 may keep a log of who has access to the phone data, whouses the data, and how it is used. These measures may reduce theincidence of unauthorized employee snooping into the phone usage ofcertain customers, such as, for example, celebrities. Further,statistical and multivariate analysis may be used to extract usefulinformation, such as the fact(s) that visiting some web-sites, orinstalling and respectively running some software alone or incombinations, may cause instability. That information can be mined, andalso used to alert users, for example by email, SMS or other suitablemeans, that after installation of a certain applications, for example,their phone may become unstable etc. Also, locations of unusually highfrequency of dropped calls may be discovered, and countermeasures may beused, including but not limited to alerting the user that a femtocell athis home may help him avoid those dropped calls, or installing anauxiliary cell in a bend or hollow may solve the problems for carsdriving through that location. In yet other cases, end of life ofbattery, or programs that drain batteries may be found and users alertedeither obtain a new battery or turn off power hogging software. Thisallows the system to do some pre-emptive troubleshooting, reducing costsand making customers more satisfied with the service offerings.

FIG. 7 shows an exemplary overview of a computer system 700 as may beused in any of the various locations throughout system 400. It isexemplary of any computer that may execute code to process data. Variousmodifications and changes may be made to the computer system 700 withoutdeparting from the broader spirit and scope of the current invention.CPU 701 is connected to bus 702, to which bus is also connected memory703, nonvolatile memory 704, display 707, I/O unit 708, and networkinterface card (NIC) 713. I/O unit 708 may, typically, be connected tokeyboard 709, pointing device 710, hard disk 712, and real-time clock711. NIC 713 connects to network 714, which may be the Internet or alocal network, which local network may or may not have connections tothe Internet. Also shown as part of system 700 is power supply unit 705connected, in this example, to ac supply 706. Not shown are batteriesthat could be present, and many other devices and modifications that arewell known but are not applicable to the specific cases discussedherein.

FIG. 8 shows a more detailed overview of an exemplary system 800 similarto typical telephone/PDA device data transfer stations as are currentlyin use and are known to the inventor. In FIG. 8, testing computer 810 istypically a PC with USB and Bluetooth connectivity running phone datatransfer applications such as PC Suite, PC Tools and other phonebooktransfer applications, which typically may connect one or two handsets,such as the handset of a device under test (DUT) 801 as shown in FIG. 8.These connections are typically made via USB cables 803 (not shown) orcustom cables 804 (not shown). Each phone has its own operating systemwith software 801 a and data sets 801 b 1-n. This data may containvarious types of information, including, but not limited to, addressbook data, phone numbers, email addresses, pictures, video clips, andother types of data that may be used by cell phones and theirapplications. In some cases even the applications or the applicationdata may be transferable. Typically machine 810 would have its ownoperating system 810 a, which has multiple programs 810 b, including atest application 810 b 1 (not shown separately). Often machine 810 withoperating system 810 a and programs 810 b is actually a custom,dedicated PC, and as such it has to contain drivers or DLLs, datatables, and configuration data 810 ca-n for all the phones to which itmay be connected. These data tables and configuration data also containany known combination of programs and drivers, comprising combinationsthat are known to be functional, as well as the ones that are known tohave problems. Thus the table can indicate the existence of problems.Further, enhanced test functionality is created by downloading anadditional diagnostic program 802 that supports additional manipulationand tests beyond factory diagnostic program 801 in the device 401 undertest. As a result of having a large library of DLLs (or drivers, usedinterchangeably here) almost any data transfers between two differentphones can work. The machine can, by using the DLLs, communicate anddownload the data objects (each item typically comes down as one or moredata objects from the phone), which are then stored in machine 810temporarily and eventually sent on to the other phone, as its dataobjects, using the matching DLL. It is clear that each of these deviceshas a CPU and memory, both volatile and nonvolatile, and thus each formsa small, distinct computing device.

FIG. 9 shows an exemplary process 900 for implementation of theadditional enhanced system test software. In step 901 the diagnosticprogram is loaded into a PC, such as PC 810. In step 902 the driver fordevice under test is loaded, allowing connection between test computer810 and DUT 401. In step 903 full access to DUT 401 is set up. In step904 the enhanced diagnostics 802 are downloaded into DUT 401, whichdiagnostics permit access to data not normally available throughpreviously known access methods for any of various reasons, includingbut not limited to security restrictions. In step 905 the full data andprogram map is downloaded into PC 801 from DUT 401. In step 906 thedownloaded data is compared to a reference library that may reside indata repository 506 on server 504, or it may be downloaded from a sourcevia the Internet, or via a local intranet. This comparison shows whichdata from device 401 may be good and which data may have problems. Instep 907 results of the comparison of step 906 are flagged withsuggested corrections, such as, for example, removing certain programs,or updating or modifying certain configurations, or updating certain ofthe software or firmware of device 401 to ensure that the configurationof device 110 is functionally compliant with the most recent data storedin the data repository. In step 908, the system may offer an option ofautomatic reconfiguration. If the option is not offered or not accepted(no), the process moves to step 909, where it ends. If the option isoffered and accepted (yes), the process moves to step 910, where theperson executing the implementation of the system (process 900) isprompted on a per-item basis to accept updates and modifications. Thismanual, per-item selection of modifications is necessary because somemodifications may cause loss of data and/or applications, which the usermay be unwilling to endure. In step 911, the accepted modifications areexecuted, including configuring data, programs, and tables per useroptions. In step 912 the modified material is uploaded into DUT 401.Upon completing the uploading, the process moves to step 909, where itends. These diagnostics with data table comparison capabilities may alsohave a reminder (“nag”) function that prompts the user to load updatesthat were not accepted in step 910. For example, a user may have been ina situation, such as a business trip, where he did not trust theconnection, or the security, or he did not have time, or for some otherreason he preferred to wait until a more convenient time and place. Thesystem may also require an account password or other security mechanismto prevent unauthorized people from changing the DUT configuration. Logsof the functions may be transmitted to a server in the network operationcenter, allowing review of all past transactions by any technician whois attempting to assist the customer. Additional functionality that maybe provided include features such as radio tagging, field strength andGPS tracking, or other add-ons.

It is clear that many modifications and variations of this embodimentmay be made by one skilled in the art without departing from the spiritof the novel art of this disclosure. These modifications and variationsdo not depart from the broader spirit and scope of the invention, andthe examples cited here are to be regarded in an illustrative ratherthan a restrictive sense. For example, the application for determiningif a mobile phone device is defective can be loaded onto the device fromanother computing device either in the store or over the network. Suchapplication analyzes for problems in at least one of hardware, softwareand configuration. Further, in some cases, such application may bedownloaded from a computing device connected with a cable or a localarea wireless connection. In other cases, it may be downloaded over thewireless wide area communication network, even at the service location,or anywhere else. In some embodiments, the application continues to runafter the local test, and then subsequently transmits information aboutkey events to a server on the communication network. In someembodiments, the application will request a user password to verify theuser wishes to have it installed, and is the authorized user of thedevice. In some embodiments, the data transmitted reflects or describesat least one of the following types of events: crashes of the device,other application crashes or hang-ups, loss of signal, location, loss ofbattery power, loss of connection, user configuration changes, userapplication installation and removals, data synchronization, insertingor removing data cards. Such events are time stamped, and in case of asubsequent crash, the event log can be transmitted after the mobiledevice regains functionality.

What is needed is a system and method that allows the exchange of anykind of object between two phones, whether exchange is originallysupported by these phones or not, in a secure and safe manner. Such anexchange may be accomplished, for example, over BlueTooth, infrared, orother connection types that are well known. As discussed above, theability to insert diagnostic tools into a phone, and more specifically,the ability to insert software into a phone, is known to the inventors.

FIG. 10 shows a simplified overview of two phones, 1001 and 1011, thatare communicating with each other, according to one embodiment of thecurrent invention. Each phone 1001 and 1011 has its own store 1002 a-nand 1012 a-n, respectively, of software, such as, for example, programs.Similarly, each phone 1001 and 1011 has a set of data objects 1003 a-nand 1013 a-n, respectively. In the manner described above, the phonethat is initiating communication, in this case phone 1011, is sending adiagnostic program, which in this example is a file plan for a utility,to phone 1001.

FIG. 11 shows an exemplary process 1100 of the interaction between thetwo phones, according to one embodiment of the current invention. Thetwo communication streams are stream 1111 (for phone 1011) and stream1101 (for phone 1001). In step 1121, the initializing phone (in thisexample, phone 1012) connects to the other phone (in this example, phone1001). In step 1122, phone 1001 identifies phone 1011. In step 1123,based on the identification, an application that is suitable for theobject phone 1001 is taken from the application store, which forms partof the program store 1012, and is transferred to phone 1001. Typically,the phone's security system asks the user to confirm this transfer, andupon acceptance, in step 1124, phone 1001 accepts and installs theapplication. That application may contain a key that sets up a trustedrelationship between the two phones for the future, similar to therelationship between nodes in a home or workgroup network of computers.Different types of settings may be offered, such as, for example,“Always allow” or “Always ask” in the case of a request to transferdata. In step 1125, initiating phone 1011 sends a selected object toreceiving phone 1001, and in step 1127, receiving phone 1001 receivesthe object. The user may be prompted to accept the object, particularlydepending on the nature of the object. This process may continue untilall desired objects are transferred. In some cases, the transfers may bebidirectional; in other cases, they are only unidirectional. Both phonesend their communications in step 1129 and 1130, respectively, afterwhich a new session must be started again from step 1121 to send moredata. When the application is installed, depending on its permissionssettings, it may remain in the phones and permit new connection for datatransfers without reinstallation, or it may allow such connections onlywith user approval. However, in other cases, the application may bedeleted after each session for purposes of security.

Further Enhanced Implementation

What is needed is a system and method that can transfer the data ofeither multiple devices simultaneously or one device on a one-to-onebasis in sequence, using wireless connections and thus avoidingconnection problems such as defective connectors, unavailableinfrastructure, etc.

FIG. 12 shows transfer station 1200. Station 1200 has a phone datatransfer machine (PDTM) 1210, typically a PC with USB and Bluetoothconnectivity running phone data transfer applications such as PC Suite,PC Tools and other phonebook transfer applications, which typically mayconnect to two handsets: originating handset 1201 and a receivinghandset 1202. These connections are, in some cases, typically made viaany suitable wireless connection such as 1203 or 1204, including, butnot limited to, Bluetooth, Wi-Fi, ZigBee, or any other suitable wirelessprotocol, or over the wireless carrier network and via the Internet (notshown) to device 1210. For this purpose, device 110 may have one or moreadditional wireless interfaces (not shown for clarity). In some cases,these interfaces may reside in one or more access points (not shown)connected through a local area network (not shown). Also, device 1210may, in some cases, support more than two sets at a time. Thus, a singledevice could support, for example, transfer between four pairs (i.e.,total of eight devices, four old devices and four new devices). Eachphone has its own operating system with software 1201 a and 1202 a,respectively, and data sets 1201 b 1-n and 1202 b 1-n, respectively.This data may contain all kinds of information, including, but notlimited to, address book data, phone numbers, email addresses, pictures,video clips, and other types of data that may be used by cell phones andtheir applications. In some cases even the applications or theapplication data may be transferable. Typically machine 1210 would haveits own operating system 1210 a, which has multiple programs 1210 b. insome embodiments, machine 1210 with operating system 1210 a and programs1210 b is actually a custom, dedicated PC, and as such it containsdrivers or DLLs 1210 c for all the phones to which it may be connected.As a result of having a large library of DLLs (or drivers, usedinterchangeably here) almost any data transfers between two differentphones can work. The machine can, by using the DLLs, communicate anddownload the data objects (each item typically comes down as one or moredata objects from the phone), which are then stored in machine 1210temporarily and eventually sent on to the other phone, as its dataobjects, using the matching DLL. In various embodiments, each of thesedevices has a CPU and memory, both volatile and nonvolatile, and thuseach forms a small, distinct computing device.

What is needed is a system and method that allows connection oftelephone devices of unknown or questionable origin, with incorrect orspoofed VID/PID, and the ability to provide services such as datatransfer, software repair of damaged flash, etc.

FIG. 13 shows an exemplary process 1300, according to one aspect of thesystem and method disclosed herein, for discovering the actual identityof a telephone device, which actual identity may differ from theindicated identity of said device, and installing correct drivers forsaid device. A device under test (DUT) 401 is connected via a wiredconnection or wirelessly to system 1300. At step 1303 the systemattempts to determine the ID of DUT 401, typically by determining theVID/PID from the USB or from the wireless plug ‘n’ plays used. Ingeneral, only a few actual distinct platforms of chipsets, symbolized aselements in list 1302 a-n, are widely used. Currently about seven mainplatforms are in use, including, but not limited to, platforms fromchipset manufacturers such as MTK, Infineon, Motorola, Qualcomm, Nokia,etc. However, myriad variations are made in designing telephone ormobile computing devices using those chipsets, both in the chipsets fromthe chipset manufacturers mentioned above, as well in as custommodifications by handset manufacturers that add additional chips,software, and software modifications, resulting in a complex, vast arrayof combinations and permutations of the platform elements used in adevice, sometimes within the same VID/PID. This VID/PID (referred to asID here) is then compared to the contents of a look-up table 1304, wherethe device may be identified. Table 1304 is a part of a knowledge base(not shown), which contains various tables and data accessed by thesystem. If the look-up list does not return a conclusive ID result,meaning that more than one model and/or hand set manufacturer (HSM) areusing it, the system then queries table 1305, which has multi-variantcontent. This is a list of devices that are known to have multiplevariants. Also, in some cases, the system may prompt the user to enteradditional information, or the system may send a query from server 1306.This server 1306 may be used, for example, as a common knowledge basefor all or a group of service entities, such as, for example, within acertain store network, or provider network, to allow knowledge acquiredat one entity to be shared among all entities. Queries to a user mayinclude a request that the user manually enter an International MobileEquipment Identity (IMEI) number, an electronic serial number (ESN), aserial number, or any other, similar type of marking on the device, aswell as a model number from the device. However, as previously noted,some manufacturers may mark a device with a known model number, such as,for example, N95 from Nokia or the Apple iPhone model number, eventhough the device is not from the indicated manufacturer and is, infact, a counterfeit device. Once the device has been identified, thesystem looks up its correct driver from a list of drivers in table 1307,and then in step 1308 it installs a low-functionality driver that canmake additional queries into the handset's operating system in step 1309for further identification of a HSM and model number. The results ofthese queries are applied to a second look-up table 1310 that lists ofall the drivers. With the correct driver determined from table 1310, instep 1311 the system uninstalls the low-functionality driver and, instep 1312, it installs the correct driver.

FIG. 14 shows an overview of an exemplary table 1400, typical of tables1304, 1307, or 1310. Table 1400 shows OEM IDs O1 through On 1402 a-n andmodel numbers M1 through Mn 1401 a-n. Thus a user or the system asdisclosed herein may create a cross reference 1403 aa-nn from the OEM IDand the model numbers appearing within a certain VID/PID of that OEM.Some OEMs, for example, use the same VID/PID for several model numbersas they quickly change chip versions, but do not change the overalldevice architecture. However, different chip versions may have differentfunctions and features, as well as different internal memory, and thusmay need different diagnostic tools and/or different transfer tools torecover and transfer and reinstall the operating system, as well asapplications, data, and user information, such as calendar, addressbook, images, video, etc. By providing this dynamic look-up andproblem-management tool, the system can flexibly adapt itself.

FIG. 15 shows an additional aspect of the system and method disclosedhere, namely, an innovation to speed up the process as, during thediscovery of a device, multiple drivers may need to be exchanged, andthat operation can take a long time using the typical plug ‘n’ playprocess. A new approach for exchanging drivers is herein proposed:

FIG. 15 a shows an overview of a classic driver model 1500 as is wellknown in the art, with the application 1501 sitting on top of the driver1502 and the OS 1503 sitting below, and the driver having the VID/PIDand other interfaces to software and hardware plug ‘n’ play, etc., asindicated by elements 1504 a-n, and interfaces to the applications 1505a-n.

FIG. 15 b shows a novel approach 1510 for a driver stack layer view,according to one aspect of the system and method disclosed herein.Reinstalling the whole driver every time requires massive changes in theregistry. In the novel approach of the system and method disclosedherein, for drivers that have the same VID/PID (or even differentVID/PID in some cases), the driver is cut into three sections:application-facing 1511 (with subsections 1505 a-n)” the main body 1512x (which can be now exchanged without requiring a reboot), and OS-facingsection 1513 (with subsections 1514 xy out of 1514 aa-nn). In thisembodiment, section 1511, which contains certain functional elements1505 a-n of the driver, is now absorbed as part of the application 1501and, as such, is no longer a part of the driver. Section 1512 x containsthe remaining portions of the driver, which, in many applications, canbe represented by a uniform driver that has a small footprint and canload relatively quickly. This novel approach no longer requires theloading of all functional elements in 1511 with its subsections 1505 a-nand 1512 x, which may require a long time to load, but only the uniformdriver 1512 together with selected functional elements 1505 a-n in 1511that are necessary to interface to a particular device. Not having toload unnecessary functions can save a significant amount of time.Further, section 1513 interfaces to the OS, and main driver section 1511x can be easily interchanged with any of 151 la-n (not shown), withoutrequiring a reboot every time.

In some cases, the VID/PID is exchanged by writing directly into theregistry, rather than by a full plug ‘n’ play installation. This novelapproach has the advantage that the typical change time is now in themillisecond or low seconds range, instead of the tens of secondstypically required currently to uninstall and reinstall a driver.Because up to a dozen or two dozen drivers may need to be tested for asingle a phone, the total time to test drivers could become a burden toa business if each uninstall and reinstall cycle of a driver takes up toa minute or longer.

FIG. 16 shows an overview of an exemplary device 1600 according to oneaspect of the system and method disclosed herein. Device 1600 is, inthis example, a USB key 1601. Device-oriented port 1602 can accept astandard USB interface cable for connection from a small mobilecommunication device (not shown). Computer-oriented connector 1603 mayplug into a computing device (not shown), such as the exemplary computerof FIG. 7 or any other, similar standard PC. Connector 1603 may,alternatively, plug into a USB power supply (not shown) to supply powerto USB key 1601, if the communication device to which it is attacheddoes not supply enough power. A user may press button 1604 to initiateoperation of USB key 1601. (It is clear that button 1604 is exemplaryonly, and that any of various types of switches, buttons, toggles, keys,etc. may be used to initiate operation.) In some cases a medium foraddition data storage may plug into slot 1605. USB key 1601 also has asmall display 1606.

FIG. 17 shows an overview of device architecture 1700, according to oneaspect of the system and method disclosed herein. Again, computer-facingUSB connector 1603 is connected via USB cable 1711 to a computer 1712,of the type of complete computer system shown in FIG. 7. The unit 1601contains, in this example, system on a chip (SOC) 1701. SOC 1701 containa processor, some volatile memory, and some nonvolatile memory. Thenonvolatile memory contains software 1710 a-n and additional modulesdescribed later. It is also used to store and/or to provide informationsuch as address book data, pictures, music, or any other informationuseable on smart phone 1714, as well as the embedded operating system,and drivers and tables to communicate with a variety of differentdevices 1714. Device-facing interface 1602 is connected via USB cable1713 to communication device 1714. Display 1606 may comprise just oneLED, a multi-color LED, multiple LEDs, a small LCD, or any other,similar display type. The SOC 1701 has specific interfaces, such as1706, to drive and/or interface with respective units, such as, in thiscase, display 1606 (and/or other output devices, such as OLEDs, LEDs,LCDs, etc.). Port 1705 serves for connecting additional storage, in thisexample, to slot 1605, which may accept a micro SD card 1708. Otherinterfaces may be supported as well, but are not shown for clarity.Button 1604 is also connected to the SOC via interface 1704; in asimilar manner, computer-facing USB connector 1603 is connected to SOC1701 through interface 1703. Internal memory 1706 contains at least aboot-strap software for SOC 1701. External, additional nonvolatilememory 1707, may contain additional code, drivers, etc., as described inthe discussion of FIG. 18, following. Memory 1707 may or may not bepresent. In some cases, the system memory 1706 may have minimalcapacity, and it may only transfer data between smart phone 1714 andcomputer 1712. In other cases, memory 1707 may have limited capacity,requiring the presence of external memory 1708 for full backups. In somecases, for example, without external memory 1708, device 1600 could backup only, for example, information about 100 contacts; whereas, theaddition of external memory 1708 (for example, a flash memory card)would enable backup of all data in the communication device, includingeven pictures, music, and video. After connecting the device 1601 tophone 1714, and, if necessary, to a power source, such as computer 1712(or in lieu, not shown, a USB battery pack) to power it up if no poweris available from smart phone 1714, as indicated by lack of a light ondisplay 1606, it is then used, as described throughout this disclosure.

FIG. 18 shows a detailed overview of an exemplary system 1800 forupdating software in device 1601 to enable connecting it to a mobilecommunication device 1714 for which it does not have information,according to one embodiment of the system and method disclosed herein.In FIG. 18, computer 1712 is typically a PC with USB and Bluetoothconnectivity running phone data transfer applications such as PC Suite,PC Tools and other phonebook transfer applications, which typically mayconnect one or two handsets, such as the handset of a device under test(DUT) 1714 as shown in FIG. 18. These connections are typically made viaUSB cables 1711 and 1713. Computer 1712 has its own operating system1802 with software 1803 a-n and data sets or embedded operating systems1804 a-n (not shown) for execution on SOC 1701 in device 1601. This datamay contain all kinds of information, including, but not limited to,address book data, phone numbers, email addresses, pictures, videoclips, and other types of data that may be used by cell phones and theirapplications. In some cases even the applications or the applicationdata may be transferable. Typically computer or machine 1712 would haveits own operating system 1802, which has multiple programs 1803 a-n,including a probing/programming application 1803 x (not shownseparately).

Often computer 1712 with operating system 1802 and programs 1810 b (notshown) is actually a standard PC, and as such it often has lots ofother, not relevant software as well. It can combine DLLs, data tables,and configuration data 1804 aa-nn for most phones 1714 to which it maybe connected via unit 1601. These data tables and configuration dataalso contain an identification of combinations of programs and driversthat are known to be functional, as well as combinations that are knownto have problems. Thus the table can indicate the existence of problems.If a driver is not supported, a new configuration is prepared and loadedinto device 1601, as described later in more detail. Operating system1710 a of unit 1601 is typically an embedded type, such as Unix, Linuxor some other, similar embedded, dedicated system. It uses certainprograms 1710 b a-n, and they use drivers or driver tables 1710 c a-n.Driver tables, in this example, enable a device to use a formulaicdriver, instead of a device-specific driver, said formulaic driver usingtables and scripts that provide the actual driver functions for thespecific device. Thus a single software instance may offer drivers for avariety of devices. However, no matter how diligently a formulaic driveris designed, the number of drivers in the device may be limited by thecapacity limitations of memories 1706 and 1707. Additionally, as novelsmart phones 1714 appear in the market that are not supported by theexisting drivers 1710 c a-n. Computer 1712, which connects via cable1711 to unit 1601, has its own operating system 1802, typically aWindows or Linux operating system, and it has an application 1803 x thatcontains an enclosed environment 1803 y that can assemble and create newoperating environments for unit 1601, including but not limited to theembedded operating system and its drivers. Thus computer 1712 creates anew image in its internal memory 1810, and then the image is transferredto a flash memory, such as, for example, external memory 1708 in unit1601, and from there the internal memory 1706 (not shown here) can beused to reprogram itself and/or internal memory 1707 (not shown here,but shown in FIG. 17). This image transfer and reprogramming enables thesystem to very easily reprogram the firmware in USB key 1601 to adapt tonew devices that have not previously been supported. Computer 1712, inturn, can connect via Internet 1801 to expert system as explained in thediscussion of FIG. 13, previously, at step 1303, which has access to allthe databases of all the drivers and formats for connecting to devices.To identify new communication devices, such as device 1714, the systemcan switch unit 1601 into transparent mode, enabling the more powerfulsoftware in computer 1712 to probe device 1714, to determine its modeland possibly the parameters needed to parameterize new drivers. Thesystem can then store those new drivers and/or tables in tables 1804,report them back to 1303 for its database, and then recreate a newenvironment in memory 1810 that can be reflashed into key 1601, whichfrom now on can service device 1714 independently, without connecting tocomputer 1712. In some cases, however, key 1601 may still need a powersupply device, such as a USB battery, to supply power if the device 1714cannot supply sufficient power to operate the processor 1701 and otheritems in key 1601. Further, in cases where no suitable driver and ortable is present, by downloading an additional diagnostic program 1803 z(not shown separately) that supports additional manipulation and testsbeyond programs already present in 1803 a-n and/or drivers and tables in1804 aa-nn, newer smart phones can be added to the capabilities ofdevice 1601. As a result of having a large library of DLLs (or drivers,used interchangeably here) almost any data transfers between twodifferent phones can work. The computer 1712 can, by using the availabledrivers and tables, communicate via device 1601 with smart phone 1714and test download of data objects (each item typically comes down as oneor more data objects from the phone), and thus identify the correctcombination, which is then stored in memory 1810 of computer 1712temporarily and eventually sent on to device 1601, as described later,enabling it to connect the phone 1714 by itself, for backing up dataobjects, without use of a computer 1712. Each of these devices may havea CPU and memory, both volatile and nonvolatile, and thus each can forma small, distinct computing device.

FIG. 19 shows an exemplary process 1900 for updating software in adevice 1601. In step 1901, the system switches unit 1601 to transparentmode. In step 1902, computer 1712 probes mobile communication device1714 (via device 1601, which is now transparent) to determine its modeland possibly the parameters needed to parameterize new drivers. In step1903 the system looks up the identity and drivers of device 1714 on bothlocal computer 1712 and a remote expert system, as explained in thediscussion of FIG. 13, previously, at step 1303. In step 1904, thesystem creates a new embedded operating system for device 1714 withdrivers 1710 a-n. In step 1905, the system switches unit 1601 toprogrammable mode, and in step 1906, it then transfers the newly createdoperating system and drivers to unit 1601. In step 1907, the device 1601is reflashed, meaning that part or all of the content of the softwaresection of one or more of its nonvolatile memory units (typically, butnot always flash memory) is reprogrammed with the downloaded data fromstep 1906, making the change definitive. In step 1908, the systemrestarts the operating system of unit 1601, and then the processterminates.

FIG. 20 shows an exemplary process 2000 for backing up data from amobile communication device, such as device 1714, according to oneaspect of the system and method disclosed herein. In step 2001, unit1601 is begins operation. In step 2002, unit 1601 determines whether itcontains information about the identity of device 1714. If it does not(no), the process moves to step 2003, where it displays a messageindicating that it cannot identify device 1714. In step 2004, unit 1601checks to determine whether it is connected to a computer, such ascomputer 1712. If it is not (no), unit 1601 displays an error messageand the process moves back to step 2001, as it has no useable input(besides power) or output to perform any tasks. In some cases, it maywait for user input before continuing back to step 2001. If in 2004,unit 1601 detects that it is connected to a computer (yes), the processmoves to step 2006, where the system executes process 1900, describedabove, and the process ends at step 2007. If in step 2002, unit 1601determines that it does contain information about the identity of device1714 (yes), the process moves to step 2008, where unit 1601 displays amessage asking the user to choose whether to back up data from device1714 (A) or restore data to device 1714 (B). If the user elects to backup data, in step 2010 unit 1601 backs up data from device 1714 and theprocess ends at step 2007. If the user elects to restore data, unit 1601restores data to device 1714 and the process ends at step 2007.

It is clear that many modifications and variations of this embodimentmay be made by one skilled in the art without departing from the spiritof the novel art of this disclosure. For example, the device 1601 may beused with computers 1712 that do not have special software installed bymimicking a flash USB drive, and enabling them to exchange informationby reading and writing both by the computer 1712 and processor 1701 toand from that drive. In some cases, the drive may present a section withsoftware that can be installed on a guest computer 1714. In yet othercases, the device 1601 may present itself as both a USB drive and aCDROM with auto-launch, to install software, or to connect to a Website,from which software can be downloaded and installed etc. Thesemodifications and variations do not depart from the broader spirit andscope of the invention, and the examples cited here are to be regardedin an illustrative rather than a restrictive sense.

Enhanced Production System

What is needed is a system and method that enables the parallelprogramming of many handsets. One of the biggest problems is that theUSB connection used by most software for reprogramming handsets haslargely unknown limitation: At any given time only one USB device isconnected to the host controller and thus to the host. Therefore, if aUSB device sends a request while the host is talking to another USBdevice, that request may be lost. Generally, the device is expected tore-transmit by itself, which is not a problem in normal operating mode;however, often during reprogramming only a very reduced, basic I/Osystem is available, akin to a bootstrap ROM with very limitedcapabilities. As a result, if multiple handsets or mobile communicationdevices, both of which in this example are USB devices, are programmedconcurrently, often some “hang up” and the process must be restarted.This hang-up and the associated loss of time and productivity is theresult of lost communication packets between the host and the (mobilecommunication) device being reprogrammed. The way to avoid thesefrequent packet losses and restarts is to give each USB device its ownUSB tree with its own USB host controller. The host controller is thendedicated to that device only, and it has the ability to buffer commandsbefore they continue to travel through the PCI bus and into the CPU.

FIG. 21 shows an enhanced system 2100, according to one aspect of thesystem and method described herein. System 2100 has a PC 700 (similar tothe computing system described in the discussion of FIG. 7), which hasan additional enhanced PCI bus/motherboard. Two PCI bridges 2102 a and2102 b expand the number of available slots for USB peripheral devicessuch as mobile communication devices, providing up to 18 such slots.Such computers with up to 18 slots are manufactured for uses such asco-location by telephone companies. For example, 16 USB cards, each ofwhich can handle four phone lines at a time, could be plugged in.

In the case of the system and method disclosed herein, a multitude ofPCI cards may be plugged into the available PCI slots 2102 a and 2102 b,such as, for example, PCI card 2206, shown in FIG. 22. That PCI card2206 has a typical PCI USB controller chip 2201, which on one sideconnects to the PCI bus 2103. In this example, PCI card 2206 also hasfive USB ports, 2205 a-n. Typical for PCI cards are five USB ports, oneUSB host controller 2202 for USB 2.0, and one or two host controllersfor USB 1.0 hubs 2203 a, and in some cases 2203 b. Two USB 1.0 hubs arenecessary because in USB 1.0 architecture, each node typically can onlyaddress four nodes, and because the card has five ports, at least oneport must be addressed by a separate host controller. Cross-matrix 2204enables the correct connection and selection of the active port(s) tothe respective host controllers. Because this exemplary PCI USBcontroller chip 2201 has two USB 1.0 host controllers, in the case ofprogramming mobile communication devices 2210 a-n, which use USB 1.0,two such devices can be programmed concurrently, as long as each deviceconnects to its own host controller 2203 a or 2203 b. This approachavoids the loss of communication packets. Because in that configuration,once installed and set up, cross matrix 2204 does not change, ittherefore maintains a dedicated connection from each device 2210 to eachhost controller 2201.

FIG. 23 shows an enhanced USB PCI card 2301, which has its ownPCI-to-PCI bridge 2102. It creates an internal PCI bus 2303, on whichmultiple PCI USB controller chips 2302 a-d are shown. (Typically a PCIsegment is limited to four loads.) Each PCI USB controller chip could,using the same architecture described in above in the discussion of FIG.22, provide two active ports, 2305 a-n, thus supporting connection of upto eight USB devices (mobile communication devices), such as devices2210 a-n, to one PCI card. Using this type of card, the capabilities ofeven a standard office computer, for example, with typically four to sixavailable PCI slots, can be extended. The upper limit of the totalnumber of USB devices in a system is currently 127. Because themotherboard typically contains three to five USB devices and each USBhost controller, such as 2202 or 2203, count as one as well, each PCIUSB controller chip uses three USB identifiers for itself, limiting thetotal number available for external USB devices. Also, often systemperipherals, such as a sound card, web cam, keyboard, mouse, etc. may beconnected through a USB hub and therefore further reduce the number ofavailable USB identifiers. All these uses of USB identifiers must betaken into consideration when calculating how many mobile communicationdevices can be handled simultaneously by one computer.

FIG. 24 shows an overview of an exemplary system 2400 for enhanceddiagnostics according to one aspect of the system and method disclosedherein. The devices under test (DUTs) are client devices 2401 a and 2401b. DUT 2401 a connects to the Internet 2410 via wireless connection(over a network, not shown). DUT 2401 b is connected to a computer 2402.Software instances 2421 a and 2421 b are testing DUTs 2401 a and 2401 b,respectively. Also, software 2422, such as interconnectivity software ora special driver, may reside the desktop computer 2402. Between Internet2410 and load balancer 2405 is a firewall 2409. Often the firewall andthe load balancer may be combined. Also shown is a main diagnosticserver 2406, which in this case is exemplary of one or more servers.Server 2407 manages a diagnostic database. All servers 2406 and 2407contain, respectively, software 2436 and 2437. Similarly, customer(i.e., carrier) systems 2408 a-n contain software instances 2438 a-n.Diagnostic server 2406 may download diagnostic and background data aswell as any other related data into server 2404, which may be a localserver in the domain of a network provider. Server 2404 containssoftware 2424, which is a partial or full copy of the system and/or thedata downloaded from server 2406, or any of its connected servers.Administration console 2403 may connect to one or more server(s).Typically, console 2403 would not require special software to connect tosaid server(s), because web interface software could be used, requiringonly a web browser. In some cases, however, special client software (notshown) may be downloaded from one of the servers, or a special browserplug-in may be downloaded to enhance performance and reduce overheadduring operations.

FIG. 25 shows an exemplary process 2500 for implementation of the systemaccording to one aspect of the system and method disclosed herein. Instep 2501, the user launches the diagnostic application and screen 2511opens, wherein the user may select from a list the particularapplication with which he needs help. In step 2502 the system checks ifthere is an item in the list on the screen, and may have an “Other”field in the list, or in a different menu for the problem application.If not, in step 2503 the system asks the user what the problem is. If itturns out to be that the application exists, the system branches to step2505. If there is no app, the process continues to step 2504, where itsuggests analysis steps outside the automatic venue. The system thencontinues on to step 2507, where it performs a soft reset of the device.In step 2505, the system updates the problem app. If the problem issolved, the process moves to step 2513, where the system sends theresults to the knowledge database. If the problem is not solved, theprocess moves to step 2506, where the system deletes the application andchecks whether the problem is solved. If yes, the process moves to step2513. In those cases, the offending App can be deleted as part of atrial remedy to resolve an error. If after deletion it was found the Appwas not part of the problem, then the App would need to be restored.Data backup and subsequent restore could for example, and may beemployed in several sections and not necessarily as in this exemplaryorder. If the problem is not solved, the process moves to step 2507,where the system performs a soft reset of the device. If the problem issolved, the process again moves to step 2513; if the problem is notsolved, the process moves to step 2508, where the system performs a databackup and then moves to step 2509, where it updates the devicefirmware. If the problem is solved, the process moves to step 2511,where the system restores the data; if the problem is not solved, theprocess moves to step 2510, where the system performs a hard reset. Ifthe problem is solved, the process moves to step 2511, where the systemrestores the data; if the problem is not solved, system notes thefailure but still moves to step 2511 and restores the data. Afterrestoring the data in step 2511, the system in step 2512 suggests avisit to a repair center, and again in step 2513 sends all results, viaeither wired or wireless communication means, back through the cloud tothe knowledge database.

FIG. 26 shows an overview of the data flow 2600 as it is analyzed. Theinitial “eTicket” data 2603 (electronic Ticket or error report) isanalyzed in the device 2401 a or 2401 b respectively by some localsoftware. If that software cannot determine the nature of the problem,the investigation is escalated to the field knowledge database 2602. Ifthat examination does not yield a clear conclusion, the device log data2601 is pulled into the main diagnostic server 2406 and further analyzedthere.

FIG. 27 shows an overview of an exemplary typical screenshot 2700,according to one aspect of the system and method disclosed herein, whichscreen would appear in response to a user request for troubleshootingassistance or in response to a data analysis software conclusion that aproblem exists. Screenshot 2700 offers the user a selection of options2701 a-n for investigation. For example, if the user selects option 2701a, the battery issue, another screen opens, as shown in FIG. 28.

FIG. 28 shows an overview of an exemplary typical screenshot 2800,according to one aspect of the system and method disclosed herein. Atthe top of the screen is an array 2801 of basic information about thedevice and its functions, such as, for example, its network and itsbattery. A list 2802 of functions that use battery power and that may beenabled or disabled is presented. Also shown is an option to controlbrightness level in bar 2803. Screen timeout selections 2804 let theuser select the duration of screen illumination after any activity. Oneor more button(s) 2805 let the user move to the next step in theprocess. Additional buttons (not shown) may let the user test newsettings or selection other options.

FIG. 29 shows an overview of an exemplary typical screenshot 2900,according to one aspect of the system and method disclosed herein, whichmay open if the user selects a GPS option. Screenshot 2900 shows a mapof a selected area. Again, array 2901 shows basic information about thedevice and about this particular function. Map 2902 shows the selectedmap, with face icon 2903 representing the user's location and star 2904,the desired destination, typically in this use, the nearest availableservice location.

FIG. 30 shows an overview of an exemplary typical screenshot 3000,according to one aspect of the system and method disclosed herein, whichshows the user that the diagnostic program recommends a firmwareupgrade. Again, array 3001 shows basic information about the device andabout this particular function. Message 3002 informs the user of therecommended action and give some of the findings of the diagnosticsoftware, and button 3003 prompts the user to start the recommendedaction. Starting a firmware upgrade may include such system actions aschecking that reception quality is adequate, that the user is notdriving or flying, that battery level is adequate to complete the taskwithout crashing during the process, and that there is enough space inthe device's flash storage to ensure that user information is notoverwritten. In some cases, the system may back up user information overthe network before beginning the upgrade.

FIG. 31 shows an overview of an exemplary typical screenshot 3100,according to one aspect of the system and method disclosed herein, ofthe type that the system may display to the user on the device duringthe firmware upgrade. Graphic 3101 indicates that new firmware is movingonto the device, while progress bar 3102 shows the user the progress ofthe operation.

FIG. 32 shows an overview of a system 3200 for identifyingsoftware-created problems and operational disruptions in smart phonecomputing devices and other mobile computing devices with cellularconnections, such as, for example, tablets, etc., according to oneaspect of the system and method disclosed herein. However, mobiledevices with any type of data connection (cellular, WiFi, bluetooth orother wireless communications) should be considered possible devicesupon which to use the systems and methods described herein.

The system comprises social networking sites SNa-SNn 3201 a-n andtechnical forum sites FSa-FSn 3202 a-n, all of which sites may besearched by a type of web-site scanning software known in the art as a“spider.” In this example, two different spiders SN 3203 and FN 3206search the two types of sites 3201 a-n and 3202 a-n, respectively,because each spider has been optimized to search its respective type ofsite. Thus spider 3203 is optimized to search social networking sites3201 a-n, which sites may include, but are not limited to, such socialnetworking sites as Facebook, Twitter, Myspace, LinkedIn, etc.Similarly, spider 3206 is optimized to search technical forum sites.Spider 3203 has a list 3204 of sites to visit and a list of templates3205, each template being designed for a particular site or site subsetto optimize the extraction of data from each site. Extracted data isthen stored in data store 3210. Similarly, spiders 3206 and 3209, whichmay be copies of essentially the same software running in differentspecialized configurations, or may be completely different versions, usesite list 3207 and template set 3208, respectively. Both the list andthe template set may be amended as needed over time, typically manually,although automatic amending of their data in whole or in part iscontemplated within the scope of this invention. When data is collectedin data store 3210, the system applies a filter 3211, which filterremoves irrelevant data and organizes the relevant data by such criteriaas phone make, model number, etc., creating a list of harmfulcombinations of model IDs, OS versions, and other device characteristicsthat in conjunction with one or more programs negatively impact the userexperience. The organized data is then stored in data store 3212. In anembodiment, the system then can sort the data into types of faults andproblems and try to identify software that users blame for operatingfaults and unsafe operations.

FIG. 33 shows an exemplary process 3300 for data retrieval and analysisby system software running on a computer or server, as described aboveand throughout, according to one aspect of the system and methoddisclosed herein. In step 3301 the system starts the scanning at aspecified time. In some cases, the system may continually be scanningweb sites; in other cases, the system may scan at preset intervals suchas, for example, once a day, once a week, at particular times, or uponthe occurrence of a particular event. Some web sites have rules aboutthe specific number, size, and/or frequency of visits or downloadsallowed to site scanning software or so-called robots, and these aretypically specified in a robots.txt file at the root directory of a siteor subsection. Such site-specific rules are recorded in templates 3205and 3208. In step 3302, the system retrieves its lists 3204 and/or 3207of sites to scan, and in step 3303 it applies the templates 3205 and/or3208 to the listed sites.

With continued reference to FIG. 33, in step 3304, the system retrievesfrom data store 3350 a list of phones for which it should particularlylook on the object sites. In an embodiment, this list is user-generatedor based on error reports found at a scanning site, where incomingsuspect devices are scanned for trouble. Further, in some cases, thelist may be manually extended based on inquiries from field support, forexample in stores, as well from reports in call centers, etc. The listmay be updated whenever required automatically as reports about phonesthat are not yet listed as having problems reach a certain level orfrequency, or manually when suggestions to add certain phones are madeto the system operators. In step 3305 the system reads all the scan logsand extracts all the hits. In step 3306 the system applies filters, suchas filter 3311. Various types of filtering criteria may apply; forexample, responses that don't identify the problem phone specificallyenough or snide comments and other inappropriate language may beremoved. In step 3307 the system flags elements of interest for review.If the issue is clearly of interest (above a certain relevancy level)the system may book it directly. If the relevancy level is not highenough, but above a predetermined relevancy level so as to be ofpotential interest, in step 3308 the system presents the issue to atechnician or other suitable person for manual review. In step 3309 thesystem operators review and resolve the presented issues, and in the3310 the process ends, to begin again either immediately or asscheduled.

It is clear that many modifications and variations of the system andmethod disclosed herein may be made by one skilled in the art withoutdeparting from the spirit of the novel art of this disclosure.

In some cases, a system may be able to discover faulty conditions due tosoftware incompatibilities of software installed in smart phonecomputing devices that have a process for recording what applicationsare launched or installed, by creating a list of potentially problematicinteractions by analyzing what application was launched or installedjust prior to a crash or other operational problem. However, anyproblems between applications and operating system, driver, hardware orin combination with other apps, or any combination thereof due tosoftware incompatibilities of hardware or of software installed in saidmobile computing device may be observed and recorded. The recordings arestored in a memory on the smart phone computing device in a fail safefashion, and/or on a storage accessed over a network. A process runningon one of the networked devices may read the recordings and analyze themto obtain statistical or heuristic patterns pinpointing a program thatis creating the problems. A list or database is created that listsharmful combinations of model IDs, OS versions, and other devicecharacteristics that, in conjunction with one or more programs,negatively impact the user experience. This list or database may be usedto warn a user when he tries to download a program included in the listor database. A computer may be connected to the Internet, containing aprogram for collecting data on the Internet, by spidering or scanningwebsites, including but not limited to social network sites and forumsfor smart phone discussions. Further, the list may be used to focus onspecific programs, device characteristics or models of smart phonecomputing devices to focus the spidering on those items.

These modifications and variations do not depart from its broader spiritand scope, and the examples cited here are to be regarded in anillustrative rather than a restrictive sense.

I claim:
 1. A method, comprising: retrieving, via a computing device,from a mobile computing device having a wireless data connection, a listof applications that were launched or installed on the mobile computingdevice during a time period prior to an operational disruption, the listof applications generated via a monitoring application running on themobile computing device, wherein the monitoring application repetitivelyrecords multiple separate consecutive files listing applications thathave been launched or installed within the time period; using, via thecomputing device, a data table of combinations of incompatible programsand drivers to analyze said list of the applications that were launchedor installed, to create a list of potential fault-causing interactionsdue to software incompatibilities of hardware or of software installedin said mobile computing device; and updating, via the computing device,a knowledge database with data identifying at least one of saidpotential fault-causing interactions.
 2. The method of claim 1, whereinsaid potential fault-causing interactions comprise problems betweenapplications and one or more of: an operating system, a driver, hardwareor another application.
 3. The method of claim 1, wherein saidmonitoring application repetitively records three separate consecutivefiles by repetitively writing three files in a process wherein: a firstfile is opened, data is written to the first file, and the first file isclosed; a second file is opened, data is written to the second file, andthe second file is closed; and, a third file is opened, data is writtento the third file, and the third file is closed.
 4. The method of claim1, wherein said monitoring application is configured to selectivelyupload said files to a central data repository only when a Wi-Ficonnection is available to the mobile computing device.
 5. The method ofclaim 1, further comprising generating a notification to a user of atleast one software incompatibility or at least one recommendedmodification of said mobile computing device.
 6. The method of claim 1,further comprising updating firmware in said mobile computing deviceafter a data backup on said mobile computing device and restoring datato said mobile computing device from said data backup after said step ofupdating said firmware.
 7. The method according to claim 1, wherein thecomputing device reads said list of applications and performs analysison said list of applications to obtain statistical or heuristic patternspinpointing a program creating said problems.
 8. The method according toclaim 1, further comprising creating a database that lists harmfulcombinations of model IDs, operating system versions, and other devicecharacteristics that in conjunction with one or more programs negativelyimpact user experience.
 9. A tangible non-transitory computer readablestorage medium storing instructions, which when executed by a computingdevice instruct said computing device to perform a method comprising:retrieving from a mobile computing device having a wireless dataconnection, a list of applications that were launched or installed onthe mobile computing device during a time period prior to an operationaldisruption, the list of applications generated via a monitoringapplication running on the mobile computing device, wherein themonitoring application repetitively records multiple separateconsecutive files listing applications that have been launched orinstalled within the time period; using a data table of combinations ofincompatible programs and drivers to analyze said list of theapplications that were launched or installed, to create a list ofpotential fault-causing interactions due to software incompatibilitiesof hardware or of software installed in said mobile computing device;and updating a knowledge database with data identifying at least one ofsaid potential fault-causing interactions.
 10. A system, comprising: aprocessor; a memory storing a set of instructions, which when executedinstruct the processor to: retrieve from a mobile computing devicehaving a wireless data connection, a list of applications that werelaunched or installed on the mobile computing device during a timeperiod prior to an operational disruption, the list of applicationsgenerated via a monitoring application running on the mobile computingdevice, wherein the monitoring application repetitively records multipleseparate consecutive files listing applications that have been launchedor installed within the time period; use a data table of combinations ofincompatible programs and drivers to analyze said list of theapplications that were launched or installed, to create a list ofpotential fault-causing interactions due to software incompatibilitiesof hardware or of software installed in said mobile computing device;and update a knowledge database with data identifying at least one ofsaid potential fault-causing interactions.